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DETAILED ACTION 

This action is responsive to the Amendment/Arguments filed on July 28, 2009. Claims 1, 10-13, 
15-23, 27, 35, 37-39, 41-53 have been amended. Claims 54 and 55 have been added. Claims 1- 
55 are pending. 

Continued Examination Under 37 CFR 1.114 

1 . A request for continued examination under 37 CFR 1.114, including the fee set forth in 
37 CFR 1.17(e), was filed in this application after final rejection. Since this application is 
eligible for continued examination under 37 CFR 1.114, and the fee set forth in 37 CFR 1 . 1 7(e) 
has been timely paid, the finality of the previous Office action has been withdrawn pursuant to 
37 CFR 1.1 14. Applicant's submission filed on July 28, 2009 has been entered. 

Response to Arguments 

2. Applicant's arguments with respect to Claim Rejections under 35 U.S.C. 103(a) have 
been considered but are moot in view of the new ground(s) of rejection. 
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Claim Rejections - 35 USC § 103 

3. The following is a quotation of 35 U.S.C. 103(a) which forms the basis for all 
obviousness rejections set forth in this Office action: 

(a) A patent may not be obtained though the invention is not identically disclosed or described as set forth in 
section 102 of this title, if the differences between the subject matter sought to be patented and the prior art are 
such that the subject matter as a whole would have been obvious at the time the invention was made to a person 
having ordinary skill in the art to which said subject matter pertains. Patentability shall not be negatived by the 
manner in which the invention was made. 

4. Claims 1-15, 19-41, 45-49, 50, and 52 are rejected under 35 U.S.C. 103(a) as being 
unpatentable over Internetworking with TCP/IP to Comer and further in view of Internet-Draft 
Fast Liveness Protocol to Sandick ct al. (hereinafter "Sandick") (IDS submitted on July 12, 2004) 
and U.S. Patent Application Publication No. 2004/0121792 to Allen et al. (hereinafter "Allen"). 

5. As to Claims 1 and 27, Comer discloses for use with a node, a method and apparatus 
(referenced hereinafter as the method) comprising: 

a) accepting, using the node, status information from at least two different kinds of [. . .] 
protocols (Comer; 15.10 BGP Functionality and Message Types and 15.16 BGP KEEPALIVE 
Message, discloses determining at a first node status information for both BGP and TCP 
protocols); 

b) composing, using the node, an aggregated message including at least two indicators, 
each indicator identifying a different one of the at least two different kinds of [. . .] protocols and 
the corresponding status information from each of the at least two different kinds of [. . .] 
protocols [...] (Comer; Figure 15.10 BGP Functionality and Message Types and 15.16 BGP 
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KEEP ALIVE Message, discloses composing an aggregated keepalive message including the 
status information); and 

c) sending, using the node, the aggregated message towards a neighbor node (Comer; 
15.10 BGP Functionality and Message Types and 15.16 BGP KEEPALIVE Message, discloses 
sending the keep alive message to neighbor second node). 

Comer does not explicitly disclose, however Sandick discloses including the status 
information from the at least two different protocols as data within the aggregated message 
(Sandick; 4.2 Parameters and B.l Flip Advertisement Message; list of neighbor interfaces as data 
in the message that indicates the status of the interfaces). 

It would have been obvious to one of ordinary skill in the art at the time the invention 
was made to modify status information and an aggregated message, as disclosed by Comer, to 
include explicitly indicating multiple statuses as data within the aggregated message, as 
disclosed by Sandick, in order to employ known methods of explicitly indicating status in a 
message. 

Comer does not explicitly disclose, however Allen discloses that the multiple protocols 
reported on may both be routing protocols (Allen; paragraph 29; routing protocols) and that the 
message includes an indicator explicitly indicating the status of each of the two different kinds of 
routing protocols (Allen; paragraph 29; binary flags indicating the status of the routing 
protocols). 

It would have been obvious to one of ordinary skill in the art at the time the invention 
was made to modify the system disclosed by Comer, to include reporting on multiple routing 
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protocols and explicitly indicating the status of each of the two different kinds of routing 
protocols, as disclosed by Allen, in order to apply the discovery taught in Comer to networks 
with heterogeneous topologies. 

6. As to Claims 2 and 28, Comer, Sandick, and Allen disclose each and every limitation of 
Claims 1 and 27. Sandick further discloses: 

d) maintaining, using the node, a first timer for tracking a send time interval, wherein the 
acts of composing the aggregated message and sending the aggregated message are performed 
after expiration of the first timer (Sandick; 4.2 Parameters and 5.3 Finite State Machine for Hello 
Message Exchange, discloses maintaining a Hellolnterval timer to determine how often FLIP 
hello messages should be sent); and 

e) restarting, using the node, the first timer after the aggregated message is sent (Sandick; 
4.2 Parameters and 5.3 Finite state machine for Hello Message Exchange, discloses restarting the 
timer after the message is sent). 

It would have been obvious to one of ordinary skill in the art at the time the invention 
was made to modify composing and sending an aggregated message, as disclosed by Comer, to 
include a send time interval and associated first timer, as disclosed by Sandick, in order to 
facilitate neighbor or peer protocol failure detection (Sandick; Abstract and 4.2 Parameters). 

7. As to Claims 3 and 29, Comer, Sandick, and Allen disclose each and every limitation of 
Claims 1 and 27. Sandick further discloses wherein the aggregated message further includes a 
dead time interval, and wherein the send time interval is less than the dead time interval 
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(Sandick; 4.2 Parameters and 5.3 Finite State Machine for Hello Message Exchange, discloses a 
PeerDeadlnterval, included in a FLIP Advertisement, that is larger than the Hellolnterval and 
that indicates how long a device should wait from the last Hello before declaring a neighbor 
failure). 

It would have been obvious to one of ordinary skill in the art at the time the invention 
was made to modify an aggregated message, as disclosed by Comer, to include a dead time 
interval which is greater than the send time interval, as disclosed by Sandick, in order to facilitate 
neighbor or peer protocol failure detection (Sandick; Abstract and 4.2 Parameters). 

8. As to Claims 4 and 30, Comer, Sandick, and Allen disclose each and every limitation of 
Claims 1 and 27. Sandick further discloses discloses wherein the aggregated message further 
includes a dead time interval, and wherein the send time interval is no more than one third of the 
dead time interval (Sandick; 4.2 Parameters and 5.3 Finite State Machine for Hello Message 
Exchange, discloses a PeerDeadlnterval, included in the FLIP Advertisement, that is at least 3 
times the value of the Hellolnterval). 

It would have been obvious to one of ordinary skill in the art at the time the invention 
was made to modify an aggregated message, as disclosed by Comer, to include a dead time 
interval which is greater than 3 times the send time interval, as disclosed by Sandick, in order to 
facilitate neighbor or peer protocol failure detection and prevent erroneous declaration of a peer 
protocol failure in a situation where a message was lost in transmission (Sandick; Abstract and 
4.2 Parameters). 
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9. As to Claims 5 and 31, Comer, Sandick, and Allen disclose each and every limitation of 
Claims 1 and 27. Sandick further discloses wherein the send time interval is less than one 
second (Sandick; 7.2 Hellolnterval, discloses the Hellolnterval default value is 3 ms). 

It would have been obvious to one of ordinary skill in the art at the time the invention 
was made to modify composing and sending a message, as disclosed by Comer, to include a send 
time interval that is less than one second, as disclosed by Sandick, in order to facilitate neighbor 
or peer protocol failure detection and expedite the detection and thereby the correction of a 
failure (Sandick; Abstract). 

10. As to Claims 6 and 32, Comer, Sandick, and Allen disclose each and every limitation of 
Claims 1 and 27. Sandick further discloses wherein the send time interval is less than 100 msec 
(Sandick; 7.2 Hellolnterval, discloses the Hellolnterval default value is 3 ms). 

It would have been obvious to one of ordinary skill in the art at the time the invention 
was made to modify composing and sending a message, as disclosed by Comer, to include a send 
time interval that is less than 100 ms, as disclosed by Sandick, in order to facilitate neighbor or 
peer protocol failure detection and expedite the detection and thereby the correction of a failure 
(Sandick; Abstract). 

11. As to Claims 7 and 33, Comer, Sandick, and Allen disclose each and every limitation of 
Claims 1 and 27. Sandick further discloses wherein the aggregated message further includes a 
dead time interval (Sandick; 4.2 Parameters, discloses a PeerDeadlnterval included in the FLIP 
Advertisement). 
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It would have been obvious to one of ordinary skill in the art at the time the invention 
was made to modify an aggregated message, as disclosed by Comer, to include a dead time 
interval, as disclosed by Sandick, in order to facilitate neighbor or peer protocol failure detection 
(Sandick; Abstract and 4.2 Parameters). 

12. As to Claims 8 and 34, Comer, Sandick, and Allen disclose each and every limitation of 
Claims 1 and 27. Sandick further discloses wherein the act of sending the aggregated message 
includes providing the aggregated message in an Internet protocol packet (Sandick; Abstract and 
Introduction, discloses sending a message using Internet protocol). 

It would have been obvious to one of ordinary skill in the art at the time the invention 
was made to modify sending an aggregated message, as disclosed by Comer, to include 
providing the message in an Internet protocol packet, as disclosed by Sandick, in order to 
facilitate neighbor or peer protocol failure detection in IP networks (Sandick; Abstract and 
Introduction). 

13. As to Claims 9 and 35, Comer, Sandick, and Allen disclose each and every limitation of 
claims 8 and 34. Sandick further discloses wherein the act of sending the aggregated message 
towards the neighbor node includes setting a destination address in the Internet protocol packet 
to a multicast address associated with routers that support aggregated protocol liveness (Sandick; 
4. 1 Neighbor Discovery, 4.2 Parameters, and 4.6 Finite State Machine for Neighbor Adjacency, 
discloses the sending the message as a multicast message to a neighbor node by setting the 
destination address to a multicast address). 
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It would have been obvious to one of ordinary skill in the art at the time the invention 
was made to modify sending an aggregated message in an IP packet, as disclosed by Comer, as 
modified by Sandick, to include setting a destination address in the Internet protocol packet to a 
multicast address, as disclosed by Sandick, in order to facilitate neighbor or peer protocol failure 
detection on a subnet (Sandick; 4. 1 Neighbor Discovery, 4.2 Parameters, and 4.6 Finite State 
Machine for Neighbor Adjacency). 

14. As to Claims 10 and 36, Comer, Sandick, and Allen disclose each and every limitation of 
Claims 1 and 27. Comer further discloses wherein the neighbor node has at least one routing 
protocol peering with at least one of the at least two routing protocols (Comer; 15.10 BGP 
Functionality and Message Types and 15.16 BGP KEEPALIVE Message, discloses the neighbor 
node has at least one protocol peering with one of the protocols in the first node). 

15. As to Claims 1 1 and 37, Comer, Sandick, and Allen disclose each and every limitation of 
Claims 1 and 27. Comer further discloses wherein the status information includes a routing 
protocol state selected from a group of routing protocols states consisting of (A) protocol up, (B) 
protocol down, (C) protocol not reporting, and (D) protocol restarting (Comer; 15.10 BGP 
Functionality and Message Types and 15.16 BGP KEEPALIVE Message, discloses that status of 
the protocol is indicated by the ability of the node or the protocol to send messages. A peer 
protocol receiving the message indicates that the protocol state is up, and failure to receive the 
message indicates the protocol state is down). 
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16. As to Claims 12 and 38, Comer discloses for use with a node, a method and elements 

(referenced hereinafter as the method) comprising: 

a) receiving, using the node, an aggregated message including 

i) for a first set of at least two different kinds of [. . .] protocols of a neighbor node, 
at least two indicators, each indicator identifying a different one of the at least two 
different kinds of [. . .] protocols and the corresponding status information for each of the 
protocols of the first set of the at least two different kinds of [. . .] protocols [. . .] (Comer; 
15.10 BGP Functionality and Message Types and 15.16 BGP KEEP ALIVE Message, 
discloses receiving the BGP keepalive message including status information about the 
neighbor BGP and TCP), and 

Comer does not explicitly disclose, however Sandick discloses including the 
status information from the at least two different protocols as data within the aggregated 
message (Sandick; 4.2 Parameters and B.l Flip Advertisement Message; list of neighbor 
interfaces as data in the message that indicates the status of the interfaces) and ii) a time 
interval (Sandick; 4.2 Parameters, PeerDeadlnterval included in the FLIP 
Advertisement); and 

It would have been obvious to one of ordinary skill in the art at the time the 
invention was made to modify status information and an aggregated message, as 
disclosed by Comer, to include explicitly indicating multiple statuses as data within the 
aggregated message and to include a dead time interval, as disclosed by Sandick, in order 
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to employ known methods of explicitly indicating status in a message and to facilitate 
neighbor or peer protocol failure detection (Sandick; Abstract and 4.2 Parameters). 

Comer further discloses b) updating neighbor node protocol status information 
using the message (Comer; 15.10 BGP Functionality and Message Types and 15.16 BGP 
KEEP ALIVE Message, discloses updating TCP and BGP connection status information 
using the message). 

Comer does not explicitly disclose, however Allen discloses that the multiple 
protocols reported on may both be routing protocols (Allen; paragraph 29; routing 
protocols) and that the message includes an indicator explicitly indicating the status of 
each of the two different kinds of routing protocols (Allen; paragraph 29; binary flags 
indicating the status of the routing protocols). 

It would have been obvious to one of ordinary skill in the art at the time the 
invention was made to modify the system disclosed by Comer, to include reporting on 
multiple routing protocols and explicitly indicating the status of each of the two different 
kinds of routing protocols, as disclosed by Allen, in order to apply the discovery taught in 
Comer to networks with heterogeneous topologies. 

17. As to Claims 13 and 39, Comer, Sandick, and Allen disclose each and every limitation of 
Claims 12 and 38. 
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Sandick further discloses wherein the act of updating neighbor node protocol status 
information includes 

i) setting, using the node, a first timer to the time interval and starting the first timer 
(Sandick; 5.3 Finite State Machine for Hello Message Exchange, discloses a setting a 
PeerDeadlnterval timer to a PeerDeadlnterval), 

Comer further discloses ii) if the first timer expires, setting, using the node, the status of 
each of the protocols of the neighbor node to down (Comer; 15.10 BGP Functionality and 
Message Types and 15.16 BGP KEEPALIVE Message, discloses setting the status of the BGP 
and TCP protocols of the neighbor node to down when the timer expires) (Sandick; 5.3 Finite 
State Machine for Hello Message Exchange, discloses setting the status of a peer protocol of the 
neighbor node to down when the timer expires), and 

Comer further discloses iii) if a further message, sourced from the neighbor node, and 
including 

A) for a second set of at least two protocols, at least two indicators, each indicator 
identifying the at least two [. . .] protocols and status information for each of the 
protocols of the second set, and 
[...] 

is received then, [ . . . ] restarting the first timer (Comer; 1 5 . 1 0 BGP Functionality and 
Message Types and 15.16 BGP KEEPALIVE Message, discloses restarting the timer in response 
to receiving a further keepalive). 
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Comer does not explicitly disclose, however Sandick discloses B) a new time interval and 
resetting the first timer to the new time interval (Sandick; 4.2 Parameters and 5.3 Finite State 
Machine for Hello Message Exchange, discloses including a PeerDeadlnterval in the FLIP 
Advertisements, and resetting the PeerDeadlnterval timer to the time interval that is received in 
the message). 

Comer does not explicitly disclose, however Allen discloses that the multiple protocols 
reported on may both be routing protocols (Allen; paragraph 29; routing protocols) and that the 
message includes an indicator explicitly indicating the status of each of the two different kinds of 
routing protocols (Allen; paragraph 29; binary flags indicating the status of the routing 
protocols). 

18. As to Claims 14 and 40, Comer, Sandick, and Allen disclose each and every limitation of 
Claims 13 and 39. Sandick further discloses wherein each of the time interval and the new time 
interval is less than one second (Sandick; 4.2 Parameters, 5.3 Finite State Machine for Hello 
Message Exchange, and 7.2 Hellolnterval, discloses a PeerDeadlnterval, included in the FLIP 
Advertisement, that is at least 3 times the value of the Hellolnterval, which has a default value of 
3 ms). 

It would have been obvious to one of ordinary skill in the art at the time the invention 
was made to modify a message, as disclosed by Comer, to include a time interval that is less than 
one second, as disclosed by Sandick, in order to facilitate neighbor or peer protocol failure 
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detection and expedite the detection and thereby the correction of a failure (Sandick; Abstract 
and Introduction). 

19. As to Claims 15 and 41, Comer, Sandick, and Allen disclose each and every limitation of 
claims 12 and 38. Comer further discloses wherein the status information includes a routing 
protocol state selected from a group of routing protocols states consisting of (A) protocol up, (B) 
protocol down, (C) protocol not reporting, and (D) protocol restarting (Comer; 15.10 BGP 
Functionality and Message Types and 15.16 BGP KEEP ALIVE Message, discloses that status of 
the protocol is indicated by the ability of the node or the protocol to send messages. A peer 
protocol receiving the message indicates that the protocol state is up, and failure to receive the 
message indicates the protocol state is down). 

20. As to Claims 19 and 45, Comer discloses a method and a system (hereinafter referred to 
as the method) for monitoring liveness of multiple protocols, the method comprising: 

a) determining, at a first node, status information for at least two different protocols 
(Comer; 15.10 BGP Functionality and Message Types and 15.16 BGP KEEPALIVE Message, 
discloses determining at a first node status information for both BGP and TCP protocols); 

b) sending, from the first node, an aggregated message including at least two indicators, 
each indicator identifying a different one of the at least two different kinds of [. . .] protocols and 
the corresponding status information from each of the at least two different kinds of [. . .] 
protocols [...] (Comer; 15.10 BGP Functionality and Message Types and 15.16 BGP 
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KEEP ALIVE Message, discloses sending a keepalive message indicating the status of the 
protocols to a second node); 

c) receiving, at the second node, the aggregated message (Comer; 15.10 BGP 
Functionality and Message Types and 15.16 BGP KEEPALIVE Message, discloses receiving the 
message at the second node); and 

d) updating, by the second node, first node protocol status information using the 
aggregated message (Comer; 15.10 BGP Functionality and Message Types and 15.16 BGP 
KEEPALIVE Message, discloses updating TCP and BGP connection status information using 
the message). 

Comer does not explicitly disclose, however Sandick discloses including the status 
information from the at least two different protocols as data within the aggregated message 
(Sandick; 4.2 Parameters and B.l Flip Advertisement Message; list of neighbor interfaces as data 
in the message that indicates the status of the interfaces). 

It would have been obvious to one of ordinary skill in the art at the time the invention 
was made to modify status information and an aggregated message, as disclosed by Comer, to 
include explicitly indicating multiple statuses as data within the aggregated message, as 
disclosed by Sandick, in order to employ known methods of explicitly indicating status in a 
message. 

Comer does not explicitly disclose, however Allen discloses that the multiple protocols 
reported on may both be routing protocols (Allen; paragraph 29; routing protocols) and that the 
message includes an indicator explicitly indicating the status of each of the two different kinds of 
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routing protocols (Allen; paragraph 29; binary flags indicating the status of the routing 
protocols). 

It would have been obvious to one of ordinary skill in the art at the time the invention 
was made to modify the system disclosed by Comer, to include reporting on multiple routing 
protocols and explicitly indicating the status of each of the two different kinds of routing 
protocols, as disclosed by Allen, in order to apply the discovery taught in Comer to networks 
with heterogeneous topologies. 

21. As to Claims 20 and 46, Comer, Sandick, and Allen disclose each and every limitation of 
Claims 19 and 45. Sandick further discloses wherein the aggregated message further includes a 
first time interval, and wherein the act of updating neighbor node routing protocol status 
information includes 

i) setting a timer to the first time interval (Sandick; 5.3 Finite State Machine for Hello 
Message Exchange, discloses a setting a PeerDeadlnterval timer to a PeerDeadlnterval); 

ii) starting the timer (Sandick; 5.3 Finite State Machine for Hello Message Exchange, 
discloses a starting the PeerDeadlnterval timer); 

iii) determining whether or not a further message including routing protocol status 
information is received from the first node by the second node before the expiration of the timer 
(Sandick; 5.3 Finite State Machine for Hello Message Exchange, discloses determining whether 
or not a further hello message including status information is received from the first node before 
the expiration of the timer); and 
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It would have been obvious to one of ordinary skill in the art at the time the invention 
was made to modify a message, as disclosed by Comer, to include determining whether a further 
message including protocol status information is received before the expiration of a timer, as 
disclosed by Sandick, in order to facilitate neighbor or peer protocol failure detection (Sandick; 
Abstract and Introduction). 

Comer further discloses iv) if it is determined that a further message including protocol 
status information is not received from the first node by the second node before the expiration of 
the timer, then informing peer protocols of the second node that the at least two protocols of the 
first node are down. (Comer; 15.10 BGP Functionality and Message Types and 15.16 BGP 
KEEP ALIVE Message, discloses informing the BGP and TCP protocols of the second node that 
the BGP and TCP protocols of the first node are down when a timer expires) (Sandick; 5.3 Finite 
State Machine for Hello Message Exchange, discloses informing a peer protocol of the second 
node that the protocol of the first node is down when the timer expires). 

22. As to Claim 21, Comer, Sandick, and Allen disclose each and every limitation of Claim 
19. Comer further discloses wherein the status information includes a routing protocol state 
selected from a group of routing protocols states consisting of (A) protocol up, (B) protocol 
down, (C) protocol not reporting, and (D) protocol restarting (Comer; 15.10 BGP Functionality 
and Message Types and 15.16 BGP KEEP ALIVE Message, discloses that status of the protocol 
is indicated by the ability of the node or the protocol to send messages. A peer protocol 
receiving the message indicates that the protocol state is up, and failure to receive the message 
indicates the protocol state is down). 
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23. As to Claim 22, Comer discloses a machine-readable medium having stored thereon a 
machine readable aggregated message comprising: 

a) at least two indicators, each indicator identifying a different one of at leasts two 
different kinds of [. . .] protocols of a node stored as data within the aggregated message and b) 
status information, for the at least two different [routing] protocols of a node, of a state of each of 
the at least two protocols (Comer; 15.10 BGP Functionality and Message Types and 15.16 BGP 
KEEP ALIVE Message, discloses sending a kccpalivc, with an indication of the state of the BGP 
and TCP protocols, this information is stored in the recipient node in order to determine 
connectivity and verify that the peer protocols still function); and 

Comer does not explicitly disclose, however Sandick discloses including the status 
information from the at least two different protocols as data within the aggregated message 
(Sandick; 4.2 Parameters and B.l Flip Advertisement Message; list of neighbor interfaces as data 
in the message that indicates the status of the interfaces) and b) a dead interval (Sandick; 4.2 
Parameters and 5.3 Finite State Machine for Hello Message Exchange, discloses including a 
PeerDeadlnterval in the message that is used by the recipient node to determine when to declare 
the peer protocol down) 

It would have been obvious to one of ordinary skill in the art at the time the invention 
was made to modify status information and an aggregated message, as disclosed by Comer, to 
include explicitly indicating multiple statuses as data within the aggregated message and to 
include a dead time interval, as disclosed by Sandick, in order to employ known methods of 
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explicitly indicating status in a message and to facilitate neighbor or peer protocol failure 
detection (Sandick; Abstract and 4.2 Parameters). 

Comer does not explicitly disclose, however Allen discloses that the multiple protocols 
reported on may both be routing protocols (Allen; paragraph 29; routing protocols) and that the 
message includes an indicator explicitly indicating the status of each of the two different kinds of 
routing protocols (Allen; paragraph 29; binary flags indicating the status of the routing 
protocols). 

It would have been obvious to one of ordinary skill in the art at the time the invention 
was made to modify the system disclosed by Comer, to include reporting on multiple routing 
protocols and explicitly indicating the status of each of the two different kinds of routing 
protocols, as disclosed by Allen, in order to apply the discovery taught in Comer to networks 
with heterogeneous topologies. 

24. As to Claim 23, Comer, Sandick, and Allen in combination disclose each and every 
limitation of Claim 22. Comer further discloses wherein the status information indicates a 
routing protocol state selected from a group of routing protocols states consisting of (A) protocol 
up, (B) protocol down, (C) protocol not reporting, and (D) protocol restarting (Comer; 15.10 
BGP Functionality and Message Types and 15.16 BGP KEEP ALIVE Message, discloses that 
status of the protocol is indicated by the ability of the node or the protocol to send messages. A 
peer protocol receiving the message indicates that the protocol state is up, and failure to receive 
the message indicates the protocol state is down). 
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25. As to Claim 24, Comer, Sandick, and Allen in combination disclose each and every 
limitation of Claim 22. Sandick further discloses c) an identifier of the node (Sandick; 1 .0 
Terminology, 5.1 Protocol Description, 5.2 Hello Message Contents, 5.3 Finite State Machine 
for Hello Message Exchange, discloses including the address of the node in the message that is 
used by the recipient node to determine the status of a particular peer). 

It would have been obvious to one of ordinary skill in the art at the time the invention 
was made to modify the data structure, as disclosed by Comer, to include an identifier of the 
node, as disclosed by Sandick, in order to facilitate neighbor or peer protocol failure detection in 
IP networks (Sandick; Abstract and Introduction). 

26. As to Claim 25, Comer, Sandick, and Allen in combination disclose each and every 
limitation of Claim 24. Sandick further discloses wherein the node is a router and wherein the 
identifier is a router identifier (Sandick; 1.0 Terminology, 5.1 Protocol Description, 5.2 Hello 
Message Contents, 5.3 Finite State Machine for Hello Message Exchange, discloses including 
the address of the node, which is a router, in the message that is used by the recipient node to 
determine the status of a particular peer). 

It would have been obvious to one of ordinary skill in the art at the time the invention 
was made to modify the data structure, as disclosed by Comer, to include an identifier of the 
router, as disclosed by Sandick, in order to facilitate neighbor or peer protocol failure detection 
in IP networks (Sandick; Abstract and Introduction). 
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27. As to Claim 26, Comer, Sandick, and Allen in combination disclose each and every 
limitation of Claim 22. Sandick further discloses c) an interface index (Sandick; Appendix B.l, 
discloses including an interface index in the message that is used by the recipient node to 
determine the interface status of a peer). 

It would have been obvious to one of ordinary skill in the art at the time the invention 
was made to modify the data structure, as disclosed by Comer, to include an interface index, as 
disclosed by Sandick, in order to facilitate neighbor or peer protocol failure detection in IP 
networks (Sandick; Abstract and Introduction). 



28. As to Claim 47, Comer, Sandick, and Allen disclose each and every limitation of claim 
46. Comer further discloses wherein the status information includes a routing protocol state 
selected from a group of routing protocols states including at least (A) protocol up, (B) protocol 
down, (C) protocol not reporting, and (D) protocol restarting (Comer; 15.10 BGP Functionality 
and Message Types and 15.16 BGP KEEPALIVE Message, discloses that status of the protocol 
is indicated by the ability of the node or the protocol to send messages. A peer protocol 
receiving the message indicates that the protocol state is up, and failure to receive the message 
indicates the protocol state is down). 

29. As to Claim 48, Comer, Sandick, and Allen disclose each and every limitation of Claim 
1 . Comer further discloses wherein the status information is local routing protocol status 
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information (Comer; 15.10 BGP Functionality and Message Types and 15.16 BGP KEEPALIVE 
Message, discloses the status information is local protocol status information). 

30. As to Claim 49, Comer, Sandick, and Allen disclose each and every limitation of Claim 
1 . Comer further discloses wherein the status information is local status information and 
wherein each of the at least two kinds of routing different protocols is being run locally on the 
node (Comer; 15.10 BGP Functionality and Message Types and 15.16 BGP KEEPALIVE 
Message, discloses the status information is local protocol status information and each of the two 
different protocols is being run locally on the node). 

31. As to Claims 50 and 52, Comer, Sandick, and Allen disclose the method of Claims 1 and 
27. Comer further discloses wherein the status information of at least one of the at least two 
different kinds of routing protocols included in the aggregated message includes a routing 
protocol state set to protocol not reporting (Comer; 15.10 BGP Functionality and Message Types 
and 15.16 BGP KEEPALIVE Message, discloses that status of the protocol is indicated by the 
ability of the node or the protocol to send messages. A peer protocol receiving the message 
indicates that the protocol state is up, and failure to receive the message indicates the protocol 
state is down, a down state indicates that the protocol is not reporting). 



Application/Control Number: 10/775,486 Page 23 

Art Unit: 2445 

32. Claims 18 and 44 are rejected under 35 U.S.C. 103(a) as being unpatentable over Comer, 
Sandick, and Allen as applied to claims 13 and 39 above, and further in view of US Patent No. 
5,349,642 issued on September 20, 1994 to Kingdon (hereinafter "Kingdon"). 

33. As to Claims 18 and 44, Comer, Sandick, and Allen in combination disclose each and 
every limitation of Claims 13 and 39. Comer, Sandick, and Allen do not explicitly disclose, 
however Kingdon discloses wherein each of the aggregated message and the further message 
include an indication of a relative message age, and wherein the act of updating neighbor node 
protocol status information includes, 

iv) if the further message is received then, in addition to resetting the first timer to the new time 
interval and restarting the first timer, further 

A) determining whether the further message is younger than the message, and 

B) if it is determined that the further message is not younger than the message, then 
discarding the further message. 

(Kingdon; Figure 5, discloses determining whether the sequence number of the further received 
message is less than the sequence number of the previously received message and if this is the 
case, discarding the further message). 

It would have been obvious to one of ordinary skill in the art at the time the invention 
was made to modify updating neighbor node protocol status information, as disclosed by Comer, 
to include consideration of the relative message age, as disclosed by Kingdon, in order to avoid 
accepting older messages that may contain information that is no longer valid. 
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34. Claims 5 1 and 53 are rejected under 35 U.S.C. 103(a) as being unpatentable over Comer, 
Sandick, and Allen as applied to claims 1 and 27 above, and further in view of U.S. Patent No. 
7,362,700 to Frick et al. (hereinafter "Frick"). 

35. As to Claims 5 1 and 53, Comer, Sandick, and Allen disclose the method of Claims 1 and 
27. Comer, Sandick, and Allen do not explicitly disclose, however Frick discloses wherein the 
status information of at least one of the at least two different protocols included in the aggregated 
message includes a protocol state set to protocol restarting (Frick; column 1 lines 60-63; LSA 
announces intent to perform a restart). 

It would have been obvious to one of ordinary skill in the art at the time the invention 
was made to modify the status information, as disclosed by Comer, to include an indication of 
restarting, as disclosed by Frick. One of ordinary skill in the art at the time the invention was 
made would have been motivated to make this combination in order to perform a hitless restart. 

36. Claims 54 and 55 are rejected under 35 U.S.C. 103(a) as being unpatentable over Comer, 
Sandick, and Allen as applied to claims 1 and 12 above. 

37. As to Claims 54 and 55, Comer, Sandick, and Allen disclose the method of Claims 1 and 
12. Although Allen does not specify that the multiple routing protocols include at least one of 
BGP, IS-IS, OSPF, RIP, etc, it would have been obvious to one of ordinary skill in the art to 
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modify Allen to incorporate these routing protocols because they were well known at the time 
the invention was made. 



Allowable Subject Matter 

38. Claims 16, 17, 42, and 43 are objected to as being dependent upon a rejected base claim, 
but would be allowable if rewritten in independent form including all of the limitations of the 
base claim and any intervening claims. 



Conclusion 

Any inquiry concerning this communication or earlier communications from the 
examiner should be directed to Vivek Krishnan whose telephone number is (571) 270-5009. The 
examiner can normally be reached on Monday through Friday from 9:00 AM to 5:30 PM EST. 

If attempts to reach the examiner by telephone are unsuccessful, the examiner's 
supervisor, Vivek Srivastava can be reached on (571) 272-7304. The fax phone number for the 
organization where this application or proceeding is assigned is 571-273-8300. 
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Information regarding the status of an application may be obtained from the Patent 
Application Information Retrieval (PAIR) system. Status information for published applications 
may be obtained from either Private PAIR or Public PAIR. Status information for unpublished 
applications is available through Private PAIR only. For more information about the PAIR 
system, see http://pair-direct.uspto.gov. Should you have questions on access to the Private PAIR 
system, contact the Electronic Business Center (EBC) at 866-217-9197 (toll-free). If you would 
like assistance from a USPTO Customer Service Representative or access to the automated 
information system, call 800-786-9199 (IN USA OR CANADA) or 571-272-1000. 

/V. K./ 

Examiner, Art Unit 2445 

/VIVEK SRIVASTAVA/ 

Supervisory Patent Examiner, Art Unit 2445 



